Recent advances in wireless communications infrastructure and hand-held devices (from smart phones to full-featured PDAs) have changed the mobile computing landscape. In today's mobile application environment, mobile applications residing on a mobile handset (MH) are a common theme. Some of these applications maintain “local state” updated either with no external interactions or by applications running on other mobile devices or back-end servers. For example, mobile workforce applications (ERP, CRM) are quite common and these applications can update local state in a variety of ways.
For example, an application responsible for mobile workforce management can update schedule information stored on MHs. In many cases, schedule updates across several mobile workers need to be coordinated in the context of a transaction. However, depending on coverage and device status, some of the updates may fail. In this case, the application could choose to only update the mobile devices that can be updated with high probability and then attempt to update the rest at some later time.
The above example application cannot be handled correctly using existing state of the art methods, because these methods do not take into account device reachability or accessibility, and device state. As a result, devices are updated in sequence, regardless of either current conditions or conditions when the “commit” was decided upon; the result is increased overhead. A general example is the case where changes to data must be committed across several mobile hosts, that is, at the command of a coordinator, each host is expected to lock resources temporarily, commit changes, and report when finished. In a mobile scenario where all parties (even coordinators) are mobile hosts, it may be more economical to first understand the situation of each mobile host before involving it in a “commit” procedure, as doing so could save resources. Put another way, in the existing state of the art, the remote application's ability to lock and/or commit resources is the only condition taken into account—its state in the physical world (e.g. distance to the coordinator) and relationship with system resources (e.g., network utilization) is ignored.
The distributed mobile services of today, as well as emerging ones, involve a large number of mobile users, each with a MH. We note that each MH has rich computing and storage capabilities, i.e., effectively capable computers, as well as communication capabilities on one or more network types, e.g. cellular, 802.11 (aka “Wi-Fi”), WiMAX, etc. MH's are always present in one particular area or “region of interest” which can be described in different ways, e.g., in terms of the cellular sector and/or cell (when present), Base Tranceiver Station (BTS) attached to the network (cellular, WiMAX, etc.), Wi-Fi Access Point, political borders (e.g., Nassau County, Village of Piscataway, etc.), GPS coordinates of the region, and/or street address.
Any of the above represents just one aspect of the MH's context. Each MH can be considered a resource of media and/or information, and the MH may have a Resource Manager (RM) process that mitigates access to the media and/or other data. For example, the MH may be capable of controlling read/write access to MH data. An MH without a RM can still participate in information exchange but in a more ad hoc, informal fashion (concurrent reads and writes on the MH's data may cause data integrity problems).
With respect to resource management, MH's can participate in services in one of several ways. For example, participation can be with an RM carefully controlling create-read-update-delete (CRUD) access, or without an RM, allowing only Read access. In addition, participation without an RM, allowing full, trusted CRUD access is possible. In this case, neither the MH nor the service is concerned with ensuring traditional atomicity, consistency, isolation and durability (ACID) properties of access or transactions.
Stored media on the MH could include one or more of the following media types and metadata, i.e., songs and playlists, Internet favorites, photographs, videos, GPS information, application logs, and/or other mixable information. An MH could also be providing middleware or “infrastructure” type services (possibly mobile) to peers, offering functions like billing, auditing, validation and/or authentication, and recommendation.
Access-style could very likely include peer-to-peer (finding peer through flooding, registries, etc.), and service-oriented (via standard W3C protocols such as UDDI, SOAP, WSDL). Either asynchronous or syncrhonous style access-style could be permitted.
Regardless of the services and types of data (datatypes) stored and shared on the MH's, any type of coordination and/or communication between devices to render that service will often require several steps. Principle examples of these coordinations and communications are committing transactions where resources are stored on multiple distributed entities, forwarding information and files to multiple parties, establishing VoIP or cellular voice calls, such as two-party or multi-party, and sending reminders or other event types to one or a group of endpoints.
A principle concern in this area is the overhead and costs of using the transmission channel to send the sometimes very numerous messages during these coordinations. For example, while the two-phase-commit (2PC) protocol helps ensure the ACID properties of transactions, it also entails roughly 4n messages, where n is the number of distributed RM's in the transaction. FIG. 1, discussed in more detail below, shows the messaging overhead created when using prior art techniques.
Similarly, call-setup and information forwarding requires large numbers of signaling and network and/or transport-level messaging. These resources are valuable, and the owners of these resources have great interest in keeping them loaded well below peak rates. In addition, false-starts and unsuccessful communications, e.g. to terminating ends that no longer want to accept the communication, are extremely wasteful and inefficient.
Note that, in most current services involving such coordinations and communications, local context is not exploited. Context is the set of circumstances and situations surrounding any event or entity. For a cellular MH, types of context could include current region of interest containing the MH, described above, current speed and direction of the MH, current state of the MH hardware, current weather in MH's region, and/or current cellular background traffic on the attached BTS.
In many cases, exploiting context requires some extra storage and computational steps, but can add significant value to the receiving party or help the intermediate party derive better, more targeted, efficient services. This is especially true for communications and coordinations where correct context information may reduce network or computational resources by intelligently modifying communications or coordination sequences.
What is needed is a system and method providing intelligent context-based adjustment of coordination and communication between multiple mobile hosts engaging in services in which application-level information can occasionally be missed or somewhat inconsistent but the service is still of value to the recipient.